Management of multiple instances of legacy application tasks

ABSTRACT

Methods, systems, and techniques for supporting access to multiple copies of a legacy task are provided. When there are multiple copies of a task present, then instead of showing the output from a single task, the task workspace area displays task representation pictograms that represent the state and inform the user regarding each particular instance of that legacy task running on the host. The user can use the interface to perform various operations, including to start a new copy of the task, to end a copy of the task, and to select one of the copies for viewing. Example embodiments provide a Role-Based Modernization System (“RBMS”), which uses these enhanced modernization techniques to provide role-based modernization of menu-based legacy applications.

TECHNICAL FIELD

The present disclosure relates to methods, systems, and techniques formodernizing menu-based legacy applications and, in particular, tomethods, systems, and techniques for providing modernization to legacyapplications that includes managing and accessing multiple instances ofa legacy application task.

BACKGROUND

Traditional computing environments were often populated by mainframecomputers such as the IBM 3270, and, eventually, mid-range computers,such as the IBM AS400. Over the years, many companies made hugeinvestments into these platforms, which were notoriously good atproviding very large, complex applications, such as accounting, generalledger, and inventory systems for running businesses of all sizes, andvertical applications which were developed to run in optimized form inthese host computing environments. Initially, users of such programsused wired terminals to directly communicate via “sessions” with thesehost environments. A user could create a secure session to communicatewith an application running on the host computing system by presentingcredentials (e.g., username and log-on information) to the host via theterminal for authentication and authorization. The application would runon the “host” computing system, receive input from the user terminal viaa session, and forward output back to the terminal via a session fordisplay. All communication between the terminal and the host computingsystem was done through sessions. Because the screens of such terminalswere traditionally black with green writing, the output from hostapplications (also referred to as “legacy” applications) wereaffectionately known as “green screens.” FIGS. 1A and 1B are examplescreen displays of “green screen” legacy application output as presentedby such prior systems. There was no direct manipulation or pixeladdressing present, the data stream was a typically 80-character streampresented line-by-line on the display screen.

Legacy applications can be typically characterized by their voluminousnumber of menus, their hierarchical access nature, and theirsession-driven state. For example, in a legacy application it is quitetypical for an end user to select upwards of 10 or more menus, eachcorresponding to a separately executable task, to get to a point in thesystem where the user can enter some data, for example in an accountingform, only to need to back all the way out and enter another set of 10or menus to obtain some related data, for example, a part number of aninventoried item in an inventory system, and then need to reenter all ofthe first set of 10 or more menus to get back to where the user wasoriginally entering the accounting data. In a single session, this canhappen hundreds if not thousands of times. Moreover, to do multiplethings at once, for example, to handle the same data entry for multiplecustomers at a time, each requires a separate session. Thus, it is easyfor a user to lose context and become frustrated.

As desktop and personal computing became more mainstream, terminalemulators, designed to run, for example, in windowed environments on apersonal computer (PC) and using the Internet, replaced the hard wiredterminals. These PCs terminal emulators, emulating the terminals, thuscontinue to communicate via sessions with the legacy applicationsrunning on these host systems. The end user runs each application in asession managed by the terminal emulator, and legacy output is returnedto the emulator. The emulator typically presents the green screenequivalent within the confines of the emulator display, often a window.FIGS. 2A and 2B are example screen displays of the same “green screen”legacy application output presented by a terminal emulator.

Over time, as graphical user interfaces (GUIs) became an expectation,and not just a nicety, increased modernization of the “green screen” wasmade available. In particular, the interfaces presented by the terminalemulators were made smarter so that some amount of enhanced graphics andvisuals could be delivered to interface to these legacy applications.For example, commands could be accessed by checkboxes instead of numericinput, menus could be directly selected, etc. FIGS. 3A and 3B areexample screen displays of recent modernization of “green screen” legacyapplication output as performed in current systems. Even though the userinterface is potentially more user-friendly, the underlying hostapplications still require access through the multitude of menus and viasessions. The protocol remains of sign on, create a session, run one ormore jobs, sign off, as many times as needed to accomplish the user'sobjective.

As a result, although computing resources have become cheaper, and manymid-range computing systems like the AS400 have replaced the oldmainframe hardware in many companies, the legacy applications continueto have their strong place in everyday use, especially in larger orgeographically distributed companies, such as companies with many branchoffices. This phenomenon is due in a large part to the investment thathas been made over the years to greatly expand the capabilities of suchapplications and to tailor the applications for a particular company'suse. Customizations may take hundreds of thousands of person-hours andsuch applications are typically rewritten, regenerated, andredistributed each time a new function or customization is needed. Thus,in instances in which companies have invested large amounts of money andresources, it may make more business sense to continue to run the legacyapplication rather than convert to another, more modern, tool. Oftentimes it is both cost and time prohibitive to do so.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawings will be provided by the Office upon request and paymentof any necessary fee.

FIGS. 1A and 1B are example screen displays of “green screen” legacyapplication output as used in prior systems.

FIGS. 2A and 2B are example screen displays of the same “green screen”legacy application output presented by a terminal emulator.

FIGS. 3A and 3B are example screen displays of more recent modernizationof “green screen” legacy application output as performed in priorsystems.

FIG. 4 is an example screen display of role-based modernization of alegacy application.

FIG. 5 is an example screen display of a legacy task modernizedaccording to techniques described herein.

FIG. 6 is an example block diagram of an example process forreorganizing a legacy application by role for use with a Role BasedModernization System such as the RolePlay.

FIG. 7 is an example block diagram of an example data structure forstoring role-based task associations for implementing role-basedmodernization of legacy applications.

FIG. 8 is an example block diagram of components of an exampleRole-Based Modernization System.

FIG. 9 is an example block diagram of an overview of an example processfor running legacy applications that have been modernized according torole-based modernization techniques.

FIG. 10 is an example block diagram of a computing system for practicingembodiments of a client computing system of a Role-Based ModernizationSystem.

FIGS. 11A-11C are example flow diagrams of example logic used by adesktop management and control module of an example Role-BasedModernization System.

FIG. 12 is an example flow diagram of example logic use by a client-sidehost interface of a Role-Based Modernization System to communicate withone or more emulators on a host computing system.

FIG. 13 is an example flow diagram of logic for further processing ofcontext information received from an example legacy application task.

FIG. 14 is an example block diagram of a computing system for practicingembodiments of a server computing system of a Role-Based ModernizationSystem.

FIG. 15 is an example block diagram of server-side components of anexample Role-Based Modernization System using session poolingtechniques.

FIG. 16 is an example block diagram of an alternative layout ofserver-side components of an example Role-Based Modernization Systemusing session

FIGS. 17A-17B are example flow diagrams of logic of an example EmulationServices Manager of a Role-Based Modernization System according tosession pooling techniques.

FIG. 18 is an example screen display of a multiple instance interfacefor access to an example legacy task.

DETAILED DESCRIPTION

Embodiments described herein provide enhanced computer- andnetwork-based methods, systems, and techniques for modernizing legacyapplications, particularly in mid-range or mainframe host computingenvironments. For the purpose of this description, legacyapplications/tasks will refer to applications/tasks that run on hostcomputing systems through sessions, regardless of their longevity.Example embodiments provide a Role-Based Modernization System (“RBMS”),which enables the reorganization of menu-based applications by role as amethod of legacy application modernization and enables user access tosuch modernized applications through one or more roles. In addition, andas a result of these modernization techniques, the RBMS supports theability to enhance such legacy applications by blending them withnon-legacy tasks and functions in a user-transparent fashion. Accordingto such modernization techniques, legacy and non-legacy tasks arepresented to users in a uniform fashion, regardless of their disparatesources, such that they can be manipulated using the same familiar GUImechanisms. The end user invokes the application tasks without beingexposed to sessions or the voluminous and detailed menu structure, andcontext is maintained between the tasks as the end user navigatesbetween them, just as if the legacy tasks were applications running inwindows in a windowing system. In addition, legacy tasks that have beenactivated (e.g., caused to run on the host) remain so, such that theuser can logout of the system, only to return later, login, and have theactive tasks still active providing they are tasks that don't terminatefor some other reason.

FIG. 4 is an example screen display of an example role-basedmodernization of a legacy application. In FIG. 4, display area 400displays a modernized application in an example RBMS environment called“RolePlay.” An indication of the current role is shown as indicator 401.The current role can be changed by selecting user interface control 402.A task workspace area 405 displays whichever task has been selected bythe user to work on. Here, task workspace area 405 currently displaysthe home “desktop” area for the current role “client” 406. Tabs 410-412indicate tasks that the user has already started (from thedesktop)—active tasks. These tasks may include both legacy applicationtasks, such as “New Order” and “Order Tracking” and non-legacyapplication tasks such as a webpage for “HotSteel, Inc”. The user canswitch between each of these tasks at will by a variety of inputmechanisms, including, for example, direct selection using a mouse orother similar input device or a hotkey, function key, favorites icon,etc. The possible tasks that have been configured for the user to use inthe “client” role 406 are shown in task list 407. Tasks, such as “NRBatch Detail” can be invoked by selecting indicator (e.g., hyperlink)422, which will result in another tab dynamically displayed along withtabs 410-412. A user with configuration privileges, such as anadministrator or other user with abilities to configure roles (e.g., aroles administrator), can configure the tasks that are available foruser selection in the client role. In the example shown, icons such asicon 421 are dynamically added to the task list 407 by the RBMS. Inaddition, the “client” role 406 has been extended to display a data feed430, which appears on the home desktop of the “client” role each time auser navigates to that home desktop. The favorites dock 450 provides alocation for the user to add indicators for quick access to tasks. Inthe example shown, indicators 451-453 enable quick access to OrderTracking, Delivery Tracking (not shown), and New Order, respectively.Hotkey list 440 provides a list of hotkeys that the user has defined forquick access to a (legacy or non-legacy) task.

For example, when the user selects the Order Tracking favorites icon451, the Order Tracking task (referred to by tab 412) is brought to theforeground. FIG. 5 is an example screen display of a selected legacytask modernized according to techniques described herein. In particular,FIG. 5 is an example screen display of the Order Tracking task shownafter a particular order has been selected. Tab 500 shows that thecurrent selected task for the Client role is “Order Tracking.” The“Main” button 510 indicates that this is the main display of the runningOrder Tracking task. User interface controls 511-514 are task extensionsthat have been configured, for example by the end user, to imbue thelegacy task with added behavior without any programming necessary. In anexample embodiment, the user can configure task extensions for roles forwhich the user has authorization to the extent a user with administratorprivileges (an administrator) has defined. Each task extension isassociated with a rule for when the extension is presented. In somecases, upon the host generating certain types of content, taskextensions may be automatically presented. In general, the RMBSautomatically and dynamically causes an extension to be presented whenthe eligibility criteria expressed by the associated rule has been met.Task workspace area 520 displays the output of the currently executingtask (here, information on a selected order). The output is filtered sothat other GUI modernizations can be added, such as a link 521 to atelecommunications application (e.g., Skype) when a phone number isdetected in the task output, or a link to a mapping program when anaddress is detected in the task output. A user interface control such aspull-down menu 530 is presented to configure the task. In particular, auser can configure such things as removing an indicator to the task fromthe favorites dock, making the task always run and appear, defining ahotkey to access the task in one user input action, and customizing byadding, deleting, or modifying available task extensions.

A user can assign a hotkey to an individual task so that the user canhave instant access to a legacy or a non-legacy task without needing toaccess “sub-” tasks of the legacy task (e.g., without navigating througha hierarchy). For example, an end user may wish to associate a hotkeywith a particular order, for example, if the user finds a need to lookat that particular order screen a lot. These user-assigned hotkeys maybe used with role-based modernization of legacy tasks to providenavigation to and from legacy tasks without starting and stoppingsessions. The user can navigate between tasks using different hotkeys.The tasks continue to run, and the task associated with the selectedhotkey is made the “current” (forefront) task displayed in the taskworkspace area.

In some instances it may be desirable for a user to have severalinstances of the same legacy task open and to navigate between them,using hotkeys or otherwise, for example, to emulate separate “sessions”of the same task but with different data and in different states. Such ascenario might occur, for example, at an order entry counter, where aclerk chooses to have some number “n” of sessions open to work with “m”customers at a time. Each customer transaction, hence each session,might be in a different state of the transaction at any moment in time.

To support such a scenario, example embodiments of an RBMS support“multi-instance” access to a particular legacy task. On the legacy taskoutput area (the task workspace area), when there are multiple copies ofa task, then instead of showing the output from a single task, the taskworkspace area displays task representation “pictograms” that representthe state and inform the user regarding each particular instance of thatlegacy task running on the host. The user can use the interface toperform various operations, including to start a new copy of the task,to end a copy of the task, and to select one of the copies for viewing.The task representation pictogram can be text and/or graphics thatconveys any type of summary data such as the task name, and some type ofdifferentiation data. Thus the task workspace area with the taskrepresentation pictograms provides a visual dialog for selection amongmultiple copies of the same task. In some embodiments, animations,audio, or other forms of identification may also be included.

FIG. 18 is an example screen display of a multiple instance interfacefor access to an example legacy task. In the example illustrated, a userhas made 7 copies of the legacy task called “Client Master” 1802 asshown by the number 1803 on the tab indicating the task workspace area1801 of the Client Master task. In this case, instead of displaying acopy of the output screen from the host legacy task in the taskworkspace area 1801, the RBMS displays 7 separate task representationpictograms 1810-1816 that each reflect the current state of anassociated copy of the legacy task running on one or more host computingsystems. Thus, for example, task representation pictogram 1810represents the Client Master task in its “Orders by Client” sub-taskstate; whereas task representation pictograms 1813, 1814, and 1816represent the Client Master task in is “Client Detail” sub-task state;task representation pictograms 1811 and 1812 represent the Client Mastertask in its initial state; and, task representation pictogram 1815represents the Client Master task in its “Order Detail” state.

Each pictogram contains summarization and identifying informationsufficient for a user to quickly identify which instance the user isinterested in. This avoids the potentially massive searching otherwiseneeded in complicated systems (e.g., order entry systems) where a usermight have so many host sessions open on a single display that it may benearly impossible to avoid confusion and prone to error. For example,the task representation pictogram 1810 for “Orders by Client” containsan indication of the state of the task (the name of the sub-task) 1822;an order identifier 1823; and a client identifier 1824. In contrast, thetask representation pictogram 1815 for “Order Detail” contains anindication of the state of the task (the name of the sub-task), an orderidentifier and other order detail information. In some embodimentsvisual cues are also provided, for example, icon 1821. The informationcan be obtained from context information detected by the client-sidehost interface when receiving the data stream from the correspondinghost task, as described further below with respect to FIGS. 9 and11A-11C.

To create a new copy of the task, the user can use a “Copy” command froma pulldown menu 1831 or can create one using the “New Session” template1820. To close a copy of the task, the user selects the “X” closebutton, for example close button 1830.

To easily access one of the copies of the legacy task, the user can usea keyboard shortcut (e.g, ALT+TAB) if defined, type in the correspondingnumber of the copy (i.e., a number between 1-9 in the embodimentillustrated), or select the task representation pictogram directly withan input device. Once a selection is made, the task workspace areachanges from the display shown in FIG. 18 to the output of the task, forexample, as shown in FIG. 5.

Thus, the interface supports a kind of state-full visual menu or dialogto multiple instances of a task. The state of the task instancerepresented by the task representation pictogram is maintained for someamount of time, potentially configurable. Accordingly, if the clientbrowser is closed and then reopened, the RBMS desktop (the taskworkspace area, task tabs, home, etc.) will be restored to its statejust prior to closing the browser.

Other and/or different aspects, although not shown, may be similarlyintegrated or presented to role-modernized tasks and applications.

Legacy applications typically comprise a series of individuallyexecutable tasks grouped into like-kind modules. Each such task istypically accessible via a single menu item on a menu, which may be partof a very large hierarchy of menus. In a typical enterprise legacyapplication, the modules typically comprise tens of thousands of taskswhich are likewise accessed via tens of thousands of menu items.

The RBMS reorganizes such menu structured legacy applications into rolesas a means for providing modernization that allows instant access totasks, thereby avoiding the menu driven (procedural) user interfacealtogether. Role-based modernization insures that tasks associated witha role are accessible to users that are using the application in thatrole, i.e., have proper authorization to conduct the associated tasks.In addition, role modernization supports the ability to extend legacyapplications and tasks with non-legacy functionality in a seamlessfashion, regardless of the source of the function. For example, in someembodiments the legacy tasks for a single “application” may be executingon remote computing systems from each other. The location of each taskcan be made purposefully transparent to the user.

FIG. 6 is an example block diagram of an example process forreorganizing a legacy application by role for use with a Role BasedModernization System such as the RolePlay. In one example embodiment, inblock 601, the tasks in the application(s) that are part of the legacyapplication or application suite are determined as part of a“reorganization” phase of the role-based modernization configurationprocess. This determination may be an automated process whereby acomputing system is used to “harvest” the possible tasks from a menudriven application definition or may be a manual or semi-automatedprocess. In an example embodiment, it is assumed that each menu item onany menu no matter how deep, is a potential task. A list of these tasksis created as a result of performing block 601. Other organizations oftasks can similarly be incorporated, such as applications where tasksare associated at some menu levels but not others.

In block 602, each task is associated with one or more roles, as definedby the modernizer of the system. This block again may be performedmanually, automatically by a computing system, or semi-automatically.For example, a “wizard” application may be provided in thisreorganization configuration phase to assist the user in providing rolenames and associating one or more roles with each task. In someembodiments, a limitation is placed on the number of tasks per rolebefore the role is to be subdivided into a plurality of smaller roleswith lesser numbers of tasks per role. Again, in some RBMS systems thisis done manually.

In block 603, the task and role associations are stored in some kind ofconfiguration repository data structure. Information for invoking thetask on the host computing system is also stored. For example, aninvocation string associated with a menu item that corresponds to a taskmay be stored as this invocation information string.

In block 604, users are defined and associated with one or more rolesare part of the configuration process. Then, the RBMS (here, RolePlay)is run.

FIG. 7 is an example block diagram of an example data structure forstoring role-based task associations for implementing role-basedmodernization of legacy applications. In data structure 700, a list oftasks 701 is provided during the reorganization phase. One or more ofpossible roles 710 is indicated as associated with each task. Inaddition, an execution specification such as an invocation string isindicated as associated with each task, so that when the task isinitially run the RBMS knows what to pass to the host computing systemto cause the task to be executed. For example, task N 704 is indicatedas associated with execution spec N by specification 705 and with Role Dby role indicator 706.

Once application tasks are reorganized by role, the RBMS can execute amultitude of tasks concurrently and allow further configurations such ashotkey access or additional non-legacy task extensions as shown in FIGS.4 and 5. Moreover, the user interface between legacy and non-legacytasks is seamless—the RBMS provides a uniform mechanism for invoking atask and displaying the results. In addition, example embodiments of theRBMS present only a single log-on for the user. Authentication andcredential management is thereafter handled automatically between theclient-side and server-side of the RBMS and with the host applications.

As illustrated in FIGS. 4-7, one such RBMS for running role-modernizedlegacy applications is the RolePlay Environment. However, the techniquesof an RBMS also may be useful to create a variety of other applicationmodernizations and systems, including environments that presentdifferent user interfaces or for different purposes.

In one embodiment, the Role-Based Modernization System comprises one ormore functional components/modules that work together to providerole-based modernization of legacy applications. These components may beimplemented in software or hardware or a combination of both. FIG. 8 isan example block diagram of components of an example Role-BasedModernization System. Client computing system 810 communicates with Hostcomputing system 830 to run one or more legacy applications. The RolePlay RBMS comprises a client portion, the RolePlay Client ComputingSystem 811, which may be for example run as part of a Web browserapplication, and a server portion, the Role Play Computing System 831.In the example illustrated, the client portion 811 comprises a displayand control module 812, one or more RolePlay data repositories 817, ahost interface 818 for communicated with the legacy tasks, and othernon-RolePlay functions and data 819. The display and control module 812further comprises an RP Desktop Management and Control module 813 forhandling the presentation events and support; a configuration and rolesupport module 815 for providing, managing and storing configuration ofapplications, roles, and users; an extension interface 814 for providingand managing task extensions and role extensions; and a task controlmodule 816 for managing task-related state and other data. The serverportion 831 comprises a Web Application server (e.g., a Service-OrientedArchitecture—SOA—server that responds to messages), one or more RolePlaydata repositories 833, and an Emulation Services Manager (ESM) 834. TheESM talks to the host operating system API using appropriate emulationprotocols (e.g., IBM 5250/3270) to interface to the legacy applicationtasks.

It is important to note that these host applications have not beenreprogrammed to run with the RBMS—access to them has been reorganizedaccording to role during a configuration process such as the onedescribed with reference to FIGS. 6 and 7. A terminal emulator, hereEmulation Services Manager (ESM) 834, still is used to invoke each taskthrough a standard host interface (e.g., using the appropriate protocolsuch as IBM 5250/3270) as if a menu item were selected by an end user. Adifference is that from the end user's point of view a completelymodernized and seamless access to each task, legacy or not, is provided.In the embodiment shown, the emulator ESM runs on the host machineitself so as to transparently provide any required session access to theapplication tasks. Other embodiments may provide an emulator in otherlocations such as on the client computing system 810 or on anothersystem.

The implementation shown in the embodiment illustrated in FIG. 8, showsclient portion 811 divided into a javascript portion, display andcontrol module 812, and a java applet portion, host interface 818. Thejava applet 818 is used to communicate directly and efficiently over asecure communications connection (e.g. using SSL or TLS) to the ESM 834.The javascript portion 812 is used to interface to the Web Application(SOA) Server 832 over a separate secure connection using, for example,HTTPS. This division of labor is done to allocate functionality to themost appropriate tool and to allow the legacy task to outputconcurrently without interference from other functions being presentedon the RolePlay display. In a typical embodiment, the java applet 818 isloaded as a consequence of an initial startup sequence on the clientside (e.g., the user navigates to a website—url—for example,“www.roleplay.com”) and is instantiated inside of a Web Browser. Also,to the extent possible, one or more configuration files are downloadedupon the client-side startup procedure, which define the roles, tasks,initial extensions, user associations if any, etc.

The display and control module 812 in conjunction with the hostinterface 818 use secure communications channel 825 to communicate withESM 834 to invoke legacy applications modernized using role-basedmodernization techniques and to display them for user input/output on adisplay screen associated with the client computing system 810. FIG. 9is an example block diagram of an overview of an example process forrunning legacy applications that have been modernized according torole-based modernization techniques. In block 901, the client-sidedisplay and control module (DCM) 812 determines a designated task, forexample, as a result of a user selecting an indicator link to the task(e.g., link 421 in FIG. 4), a hot-key, a link on the favorites dock(e.g., link 451 in FIG. 4), etc. Next, the DCM 812 determines thedesignated task is a legacy task (requiring communication with the hostcomputing system 830), and if so continues to execute at block 902,otherwise continues with other processing to process the non-legacy tasksuch as a web-based application, extension, or other code/logic module.In block 902, the DCM 812 invokes the client-side host interface (Javaapplet) 818 to forward input to the host task and/or to receive anupdated “screen” from the host task. In block 903, the client-side hostinterface 818 forwards any input received to the host ESM 834 via thesecure binary connection (e.g., secure socket layer) 825.

In block 904, the ESM routine, which is listening on connection 825,receives the request from the client-side host interface, authorizes theuser, and determines which task as been designated. Assuming thedesignated task corresponds to an already running task, in oneembodiment, the ESM finds the appropriate session corresponding to thetask and forwards the received input. In such an embodiment the ESM orother accessible module is responsible for tracking what tasks arerunning, in which sessions etc. Alternatively, if the designated taskcorresponds to a new task to be run, the ESM initiates a new session,invokes the task, and stores task identifying information. Of note, theESM separately authenticates the credentials of the user to authorizethe task invocation so as to prevent spoofing of the user. The ESM canperform this function using the original credentials supplied by theuser in an initial log-on procedure. In some embodiments as describedwith respect to FIGS. 15 and 16, sessions may be pooled, in some casesby user, and the ESM may allocate one of the pooled sessions to run thenewly requested task. The task associated information is stored in theRolePlay data repository 833.

Eventually, in block 905 the client-side host interface 818, which islistening on connection 825, receives an updated screen (i.e., streameddata) from the ESM via connection 825, filters it according to a set ofrules implemented by a rules engine, writes context information such aswhat names, phone numbers and addresses are found, modernizes the screenaccording to a set of modernization rules and eligibility criteria, anddisplays it on its associated canvas. Examples of the modernizationrules applied by the client-side host interface 818 include instructionsin the event of detecting certain text such as phone numbers and canresult in the “Skype” link 521 presented in FIG. 5 when the interface818 detects a phone number. This allows for further dynamicmodernizations to role-based modernized legacy tasks. The client-sidehost interface 818 is also detecting the present of certain data in thedata stream to decide whether eligibility criteria are met. For example,when defining a task extension, one can define when it is displayed.This timing gets translated to a “rule” which is used by a rules engineportion of the host interface 818 to detect whether it is appropriate toplace a button to be used to invoke the task extension in the display ofthe data stream on its canvas. A call-back function is registered withthe button, so that later selection of the button will cause a call-backinto the code of the client side display and control module (e.g., theextension interface 814 of the javascript module 812) to cause theassociated extension code to be executed.

The associated canvas is the current task workspace area displayed, sothe received updated host screen is then displayed to the user. Thecontext information is written to a context list, for example stored inRolePlay data repository 817, so that the display and control modulecomponents can access the information and act upon it if they so desireor forward it to consumer code, such as task extensions.

The role-based modernization techniques of RolePlay and the RBMS aregenerally applicable to any type of legacy application task. Forexample, the phrase “task” is used generally to imply any type of codemodule that is separately executable by a host computing system. Also,although certain terms are used primarily herein, other terms could beused interchangeably to yield equivalent embodiments and examples. Inaddition, terms may have alternate spellings which may or may not beexplicitly mentioned, and all such variations of terms are intended tobe included.

Example embodiments described herein provide applications, tools, datastructures and other support to implement a Role-Based ModernizationSystem to be used for accessing applications that have been modernizedby reorganizing them by role. Other embodiments of the describedtechniques may be used for other purposes. In the following description,numerous specific details are set forth, such as data formats and codesequences, etc., in order to provide a thorough understanding of thedescribed techniques. The embodiments described also can be practicedwithout some of the specific details described herein, or with otherspecific details, such as changes with respect to the ordering of thecode flow, different code flows, etc. Thus, the scope of the techniquesand/or functions described are not limited by the particular order,selection, or decomposition of steps described with reference to anyparticular routine.

FIG. 10 is an example block diagram of a computing system for practicingembodiments of a client computing system of a Role-Based ModernizationSystem. Note that a general purpose or a special purpose computingsystem suitably instructed may be used to implement an RBMS. Further,the RBMS may be implemented in software, hardware, firmware, or in somecombination to achieve the capabilities described herein.

The computing system 1000 may comprise one or more server and/or clientcomputing systems and may span distributed locations. In addition, eachblock shown may represent one or more such blocks as appropriate to aspecific embodiment or may be combined with other blocks. Moreover, thevarious blocks of the Role-Based Modernization System 1010 mayphysically reside on one or more machines, which use standard (e.g.,TCP/IP) or proprietary interprocess communication mechanisms tocommunicate with each other.

In the embodiment shown, computer system 1000 comprises a computermemory (“memory”) 1001, a display 1002, one or more Central ProcessingUnits (“CPU”) 1003, Input/Output devices 1004 (e.g., keyboard, mouse,CRT or LCD display, etc.), other computer-readable media 1005, and oneor more network connections 1006. The RBMS installed as part of WebBrowser or other client application 1010 is shown residing in memory1001. In other embodiments, some portion of the contents, some of, orall of the components of the RBMS 1010 may be stored on and/ortransmitted over the other computer-readable media 1005. The componentsof the Role-Based Modernization System 1010 preferably execute on one ormore CPUs 1003 and manage the reorganization and modernizations oflegacy tasks as described herein. Other code or programs 1030 andpotentially other data repositories, such as data repository 1020, alsoreside in the memory 1001, and preferably execute on one or more CPUs1003. Of note, one or more of the components in FIG. 10 may not bepresent in any specific implementation.

In a typical embodiment, the RBMS installed in Web Browser or otherclient application 1010 includes one or more Javascript plug-ins 1011, aJava applet host interface 1012, and role, task, and configuration datadata repository 1013. In at least some embodiments, the data repository1013 is provided external to the RBMS and is available, potentially,over one or more networks 1050. Other and/or different modules may beimplemented. In addition, the RBMS may interact via a network 1050 withapplication or other extension code 1055 that uses data received fromlegacy applications and stored in the data repository 1013, one or morehost computing systems 1060, and/or one or more server computing systems1065. Also, the role, task, and configuration data data repository 1013may be provided external to the RBMS as well, for example in a knowledgebase accessible over one or more networks 1050.

In an example embodiment, components/modules of the RBMS 1010 areimplemented using standard programming techniques. However, a range ofprogramming languages known in the art may be employed for implementingsuch example embodiments, including representative implementations ofvarious programming language paradigms, including but not limited to,object-oriented (e.g., Java, C++, C#, Smalltalk, etc.), functional(e.g., ML, Lisp, Scheme, etc.), procedural (e.g., C, Pascal, Ada,Modula, etc.), scripting (e.g., Perl, Ruby, Python, JavaScript,VBScript, etc.), declarative (e.g., SQL, Prolog, etc.), etc.

The embodiments described above may also use well-known or proprietarysynchronous or asynchronous client-server computing techniques. However,the various components may be implemented using more monolithicprogramming techniques as well, for example, as an executable running ona single CPU computer system, or alternately decomposed using a varietyof structuring techniques known in the art, including but not limitedto, multiprogramming, multithreading, client-server, or peer-to-peer,running on one or more computer systems each having one or more CPUs.Some embodiments are illustrated as executing concurrently andasynchronously and communicating using message passing techniques.Equivalent synchronous embodiments are also supported by an RBMSimplementation.

In addition, programming interfaces to the data stored as part of theRBMS Web Browser or other client application process 1010 (e.g., in thedata repository 1013) can be made available by standard means such asthrough C, C++, C#, and Java APIs; libraries for accessing files,databases, or other data repositories; through scripting languages suchas XML; or through Web servers, FTP servers, or other types of serversproviding access to stored data. The repository 1013 may be implementedas one or more database systems, file systems, or any other method knownin the art for storing such information, or any combination of theabove, including implementation using distributed computing techniques.

Also the example RBMS Web Browser or other client application 1010 maybe implemented in a distributed environment comprising multiple, evenheterogeneous, computer systems and networks. Also, one or more of themodules may themselves be distributed, pooled or otherwise grouped, suchas for load balancing, reliability or security reasons. Differentconfigurations and locations of programs and data are contemplated foruse with techniques of described herein. A variety of distributedcomputing techniques are appropriate for implementing the components ofthe illustrated embodiments in a distributed manner including but notlimited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML-RPC,JAX-RPC, SOAP, etc.) etc. Other variations are possible. Also, otherfunctionality could be provided by each component/module, or existingfunctionality could be distributed amongst the components/modules indifferent ways, yet still achieve the functions of an RBMS.

Furthermore, in some embodiments, some or all of the components of theRBMS may be implemented or provided in other manners, such as at leastpartially in firmware and/or hardware, including, but not limited to oneor more application-specific integrated circuits (ASICs), standardintegrated circuits, controllers (e.g., by executing appropriateinstructions, and including microcontrollers and/or embeddedcontrollers), field-programmable gate arrays (FPGAs), complexprogrammable logic devices (CPLDs), etc. Some or all of the systemcomponents and/or data structures may also be stored (e.g., asexecutable or other machine readable software instructions or structureddata) on a computer-readable medium (e.g., a hard disk; a memory; anetwork; or a portable media article to be read by an appropriate driveor via an appropriate connection). Some or all of the system componentsand data structures may also be stored as data signals (e.g., by beingencoded as part of a carrier wave or included as part of an analog ordigital propagated signal) on a variety of computer-readabletransmission mediums, which are then transmitted, including acrosswireless-based and wired/cable-based mediums, and may take a variety offorms (e.g., as part of a single or multiplexed analog signal, or asmultiple discrete digital packets or frames). Such computer programproducts may also take other forms in other embodiments. Accordingly,embodiments of this disclosure may be practiced with other computersystem configurations.

As described above, one of the functions of the client-side RBMS is toprovide a uniform interface for accessing tasks, be they legacy tasks ornon-legacy tasks. FIGS. 11A-11C are example flow diagrams of examplelogic used by a desktop management and control module of an exampleRole-Based Modernization System to provide uniform access. This eventhandler logic may, for example, be implemented by the RolePlay Displayand Control module 812 of FIG. 8. Blocks 1101-1123 provide an event loopfor processing different types of tasks and functions. A uniforminterface to the various tasks is effectuated by essentially shufflingthe task workspace areas between executing tasks, so that the currenttask's workspace area is “on top” in the display order. For example,task workspace area 405 in FIG. 4 is “replaced by” (by manipulating thez-order of) task workspace area 520 in FIG. 5 when the Order Trackingtask is selected by selecting the Order Tracking tab 412 in FIG. 4. In awindowing type system, the z-order refers to the z-axis—or depth intothe display screen. That is, a location in the z-order dictates whatscreen real-estate appears on top of what.

More specifically, in block 1101, the module determines what kind oftask has been designated; that is, whether an extension, legacy (host)task, or other application module has been designated. Such designationmay occur, for example, by means of a mouse or other input deviceselection, an ALT-TAB selection technique, a hotkey, a selection of anindicator on the favorites dock, etc. In block 1102, if the designatedtask is an extension, then the module continues its processing at block1103, otherwise continues at block 1305.

In block 1103, the module processes the designated extension by bringingthe task workspace area associated with the extension to overlay theprior task workspace area by moving the task workspace area associatedwith the extension to the top of the z-order. This workspace areaassociated with the extension thereby becomes the “current” taskworkspace area. The task workspace area of the extension may be aportion of the task workspace area of the underlying task, so that itappears part of that task. In block 1104, the module invokes theextension designated the current task workspace area for its output. Theextension may be a “role” extension—which is code that is authorized forall users of a particular role—or may be a task extension—which is codethat is associated with a particular task and a set of eligibilitycriteria that dictate its availability or not. The module then continuesin block 1106 to process, display, or forward any filtered or contextualinformation created by the output of the invoked extension.

In block 1105, when the module has determined that the designated taskis not an extension, the module further determines whether thedesignated task is a legacy task, thus requiring communication with anassociated host system. If so, the module continues at block 1110;otherwise, the module continues at block 1120.

In block 1110, the module determines whether the user credentialsindicate that the user is authorized to run the designated legacy task.If so, the module continues in block 1112, otherwise, the module rejectsthe request in block 1111, and returns to the beginning of the eventloop to wait for another input event. In some embodiments thisdetermination is a secondary determination of authorization as theclient RBMS has already performed a check. Such double-checking preventsagainst another system or user spoofing the RBMS by masquerading as theuser. In block 1112, the module shuffles the task workspace area toinsure that the canvas associated with the java applet host interface(e.g., java applet 818 in FIG. 8) is topmost in the z-order. This may beaccomplished in some windowing systems by moving the other taskworkspace areas to the bottom. Of note, other implementations thatutilize a different type of host interface may require other ordifferent actions to insure that the canvas (or task workspace area) ofthe host interface is topmost in the z-order. In block 1113, the moduleforwards an identifier of the designated task and appropriate inputparameters to the client-side host interface (e.g., java applet 818 inFIG. 8) to cause the designated task to be run on the host computingsystem and a resulting screen to be displayed on the client taskworkspace area (the canvas in this case). The module then continues inblock 1106 to receive the output from the invoked task and to process,display, or forward any filtered or contextual information created bythe output of the invoked task.

In block 1120, when the module has determined that the designated taskis not a legacy task, the module processes the designated non-legacytask and determines whether the user credentials indicate that the useris authorized to run the designated non-legacy task. If so, the modulecontinues in block 1122, otherwise, the module rejects the request inblock 1121, and returns to the beginning of the event loop to wait foranother input event. Again, in some embodiments this determination is asecondary determination of authorization as the client RBMS has alreadyperformed a check.

In block 1122, the module shuffles the task workspace area associatedwith the designated non-legacy task to insure that it is topmost in thez-order and becomes the current task workspace area. In block 1123, themodule invokes or otherwise processes the designated non-legacytask/application/code and designates the current task workspace area asthe active window/iframe etc., depending upon the implementation. Themodule then continues in block 1106 to receive the output from theinvoked task/application/code and to process, display, or forward anyfiltered or contextual information created by the output of the invokedtask/application/code.

The processing at block 1106 enables the module logic to processinformation that has been filtered, for example, by the host interfacereceiving a data stream from a legacy application. Such information maybe forwarded by the module logic, for example, to communicate parametersto various task extensions of the legacy task. As an example, considerthe order detail legacy task output of FIG. 5. The task workspace area520 includes several task extensions accessible through UI controls511-514. One of these task extensions is a mapping application invokedusing the directions tab 514. When the output shown in area 520 isfiltered by the display and control module (e.g., 812 in FIG. 8), theaddress of the customer is written to the context for that legacy task.When the user then selects the mapping extension via directions button514, the module forwards this address information from the context tothe mapping task extension. In other examples, although not shown, themodule itself performs some action as a result of context informationreceived.

FIG. 12 is an example flow diagram of example logic use by a client-sidehost interface module of a Role-Based Modernization System tocommunicate with one or more emulators on a host computing system to runlegacy tasks. For example, this logic may be implemented by the hostinterface 818 in FIG. 8 to communicate with the Emulation ServiceManager (ESM) 834 on a host computing system. In block 1201, the hostinterface module receives designated task input from the correspondingclient-side display and control module (e.g., module 813 in FIG. 8), forexample, as a result of executing block 1113 in FIG. 11B). In block1202, the module forwards the received input and any other parameters tothe appropriate host ESM via a secure connection, such as secure binaryconnection 825 in FIG. 8. As there may be more than one host computingsystem available to execute legacy tasks, the module may determine whichone to use. In block 1203, the module receives updated screeninformation (streamed data) from the ESM via the secure connection.Although shown as synchronous flow logic, it is understood thatequivalent asynchronous flow logic may be implemented. While the inputis received, the host interface module filters the data stream in block1204, for example, using a rules engine that implements modernizationrules and eligibility rules (the modernization rules can also be thoughtof as eligibility rules). The modernization rules identify objects inthe data stream that may be enhanced with GUI information, such as phonenumbers, addresses etc. This dynamically created information may beadded to the output to create an enhanced data stream. In addition, theeligibility rules may be used to determine when/if the module needs toadd certain other capabilities to the output. For example, in thepresence of certain things (like addresses), the user may have definedthat a mapping program extension is to be added to the task output. Itmay be then the host interface module's responsibility to add theindicators (e.g., the task buttons) for invoking these extensions, ifonly the host interface controls its canvas/task workspace area. Inblock 1205, the module displays the enhanced data stream on the currenttask workspace area, and returns.

Of note, the different logic blocks of FIG. 12, although shownseparately, may be invoked in a sort of pipeline as the data isreceived, rather than processing all of the data at each step.

FIG. 13 is an example flow diagram of logic for creating an enhanceddata stream from output received from an example legacy applicationtask. This logic corresponds to more detail executed as a result of thefiltering process of block 1204 in FIG. 12. It is one example of many ofthe functions that can be performed as a result of filtering the datareceived. In one embodiment, this logic is provided by a rules enginethat is created as a result of configuring the RBMS.

In block 1301, the logic determines whether names are found in the dataand, if so, proceeds to block 1302, otherwise continues in block 1303.In block 1302, the logic looks up in a storage repository or creates acorresponding icon and dynamically displays each corresponding icon in aposition close to the corresponding name in the enhanced output. Inblock 1303, the logic determines whether phone numbers are found in thedata and, if so, proceeds to block 1304, otherwise continues in block1305. In block 1304 the logic displays a UI control to a phoneapplication nearby each phone number in the enhanced output. In block1305, the logic determines whether addresses are found in the data, and,if so, proceeds to block 1306, otherwise continues to process otherobjects it is looking for in a similar manner until all of the legacytask output has been filtered and enhanced where indicated. In block1306, the logic displays a control to a mapping application nearby eachaddress in the enhanced output, and continues to process other objects.

FIG. 14 is an example block diagram of a computing system for practicingembodiments of a server computing system of a Role-Based ModernizationSystem. Note that a general purpose or a special purpose computingsystem suitably instructed may be used to implement an RBMS. Further,the RBMS may be implemented in software, hardware, firmware, or in somecombination to achieve the capabilities described herein.

The computing system 1400 may comprise one or more computing systems andmay span distributed locations. In addition, each block shown mayrepresent one or more such blocks as appropriate to a specificembodiment or may be combined with other blocks. Moreover, the variousblocks of the Role-Based Modernization System 1410 may physically resideon one or more machines, which use standard (e.g., TCP/IP) orproprietary interprocess communication mechanisms to communicate witheach other.

In the embodiment shown, computer system 1400 comprises a computermemory (“memory”) 1401, a display 1402, one or more Central ProcessingUnits (“CPU”) 1403, Input/Output devices 1404 (e.g., keyboard, mouse,CRT or LCD display, etc.), other computer-readable media 1405, and oneor more network connections 1406. The RBMS 1410 is shown residing inmemory 1401. In other embodiments, some portion of the contents, someof, or all of the components of the RBMS 1410 may be stored on and/ortransmitted over the other computer-readable media 1405. The componentsof the Role-Based Modernization System 1410 preferably execute on one ormore CPUs 1403 and manage the invocation and input/output to and fromlegacy tasks as described herein. Other code or programs 1430 andpotentially other data repositories, such as data repository 1420, alsoreside in the memory 1401, and preferably execute on one or more CPUs1403. In addition, a Virtual Terminal Interface 1415 to the hostoperating system, and one or more tasks, for example 1417 a and 1417 bmay be currently executing on the one or more CPUs 1403 and stored inthe memory 1401. Of note, one or more of the components in FIG. 14 maynot be present in any specific implementation. For example, in variousembodiments certain components, such as the display 1402 and/or certaininput/output devices 1404 (such as a keyboard or mouse) may not bepresent.

In at least one typical embodiment, the RBMS 1410 includes one or moreWeb Application Servers 1411, an Emulation Services Manager (ESM) 1412,pooled sessions Y14, and task and session data repository 1413. In atleast some embodiments, the data repository 1413 is provided external tothe RBMS and is available, potentially, over one or more networks 1450.Other and/or different modules may be implemented. In addition, the RBMSmay interact via a network 1450 with application or other client code1455, one or more other host computing systems 1465, for example,running remote legacy tasks, and/or one or more client computing systems1460 such as the client system demonstrated in FIG. 10. Also, the taskand session data repository 1413 may be provided external to the RBMS aswell, for example in a knowledge base accessible over one or morenetworks 1450.

As discussed with reference to the RBMS of FIG. 14, the RBMS 1410 maysimilarly be implemented in various ways and/or using various known orproprietary techniques. In particular, the RBMS 1410 may be implementedin hardware, software, and/or firmware. Software portions of the RBMS1410 may be implemented using one or more programming languages andassociated tools (e.g., compilers, interpreters, linkers, etc.) togenerate code portions (e.g., instruction sequences) that may beprocessed by hardware components (e.g., a CPU) and/or softwarecomponents (e.g., a virtual machine). In addition, the RBMS 1410 may bedecomposed, if at all, using various techniques, including client-serverarchitectures, N-tier architectures, Web Services (e.g., SOAP), classes,libraries, archives, etc.

FIG. 15 is an example block diagram of server-side components of anexample Role-Based Modernization System that includes session poolingtechniques. As described with respect to FIG. 8 and elsewhere in thepresent Figures, the client-side of the RBMS, here shown as client 1501,communicates over one or more networks 1520 with one or more hostcomputing systems, e.g., system 1510, to run role-modernized legacytasks. In example embodiments, the host computing system 1510 comprisesa Web Application 1511, which comprises Web Application Server 1512 andEmulation Services Manager (ESM) 1513. As explained elsewhere, the WebApplication Server 1512 may comprise an SOA server configured to respondto messages from the client 1501. The host computing system 1510 alsocomprises a set of host (legacy) applications 1516 and 1518, which inturn each comprise one or more tasks, for example, tasks 1517 a-1517 cand tasks 1519 a-1519 c.

In one embodiment of the RBMS (there are other server side ways tosupport role-modernization for RBMS clients), the server employs atechnique referred to as “session pooling” to multiplex between severalrunning tasks to enable the correct output to be returned to the RBMSclient in response to client requests to communicate with a particulartask. In brief, a pool of host sessions, for example pooled sessions1515 a-1515 c are created (potentially in advance or as needed) for eachuser and allocated as needed to tasks invoked by that user. Each sessionkeeps track of its own state, as sessions typically do. This state is“persistent,” even when the client is not actively working with thecorresponding legacy task, because the session that corresponds to therunning task is not terminated each time the user switches to workingwith another legacy task (maintained in a different session).Accordingly, the ESM, instead of the user, is responsible for keepingtrack of all of the running sessions and stores data as needed, forexample in data repository 833 of FIG. 8. As described further belowwith respect to FIGS. 17A-17B, when a client request for a legacy taskcomes in, typically in the form of a task identifier and various inputparameters, the Emulation Services Manager (ESM) 1514 finds thecorresponding task, and if it is already executing, switches toproviding output from the corresponding session from a session pool,otherwise allocates a new session and starts up the corresponding taskfrom an appropriate session pool. In this manner the ESM multiplexesbetween the various running legacy tasks and provides the correct outputscreens to the client RBMS 1501 without starting and stopping othersessions to do so. In typical of these embodiments the ESM 1513communicates with the operating system of the host computing system 1510using its virtual terminal services through an applications programminginterface (API). In the example illustrated, the ESM 1513 communicateswith the host environment using standard 5260/3270 protocol to manageits sessions and communicate with the legacy applications/tasks.

Of note, the pooling session techniques handling legacy task/applicationmanagement described herein may be used for purposes other than forresponding to a role-based modernization system.

FIG. 16 is an example block diagram of an alternative layout ofserver-side components of an example Roles Based Modernization Systemusing session pooling techniques. In this embodiment, the server-sideportion of the RBMS resides in a server computing system 1620 separatefrom the host computing system 1610 where the applications 1612 havinglegacy tasks 1613 a-1613 c reside. The server computing system 1620comprises the Web Application (e.g., SOA) server 1621 and the EmulationServices Manager 1622. Because the ESM 1622 is separated from the hostcomputing system 1610, it needs to communicate over the network 1630using Telnet or other protocol wrapping around the emulator protocol.

Of note, the architecture of FIG. 15 has an advantage that a singlebinary for the Web Application 1511 can be installed on the hostcomputing system that the user already has without a need to configureadditional machines. Also, in some situations it is possible that theclient-side RBMS invokes tasks that are executing or to be executed at avariety of locations, potentially even geographically remote. In such asituation, according to one embodiment, the ESM 1513 can be distributedand manage the ESMs on the other host computing environments in amaster-slave type of I/O relationship. This provides a degree oflocation transparency to the client computing system, since the clientneed only communicate with a single ESM.

FIGS. 17A-17B are example flow diagrams of logic of an example EmulationServices Manager of a Role-Based Modernization System according tosession pooling techniques. As mentioned with respect to FIG. 15, theEmulation Services Manager (ESM) may be co-resident with the hostapplications or on a remote computing system. In block 1701, the ESMauthorizes and authenticates user information forwarded by the clientRBMS for the requested task. This action protects against masqueradingand other types of malicious computing behaviors.

In block 1702, the ESM determines if the user is authorized, and, if notreturns a status to the client-side host interface that an unauthorizeduser was detected. If authorized, the ESM continues in block 1704 todetermine whether the requested legacy task is already running (in asession) and, if so, continues with block 1705; otherwise, continueswith block 1706. Since the ESM maintains and manages its pools ofsessions, it stores appropriate information to be able to make thisdetermination.

In the case where the legacy task is already running, then in block 1705the ESM determines (for example, by table look-up, database query, etc.)which session corresponds to the designated task, connects to thesession, and passes any designated parameters to the running session.The ESM then continues in block 1709.

In the case where the legacy task is not yet running, then in block 1706the ESM allocates and starts a new session from the session pool. Inblock 1707, the ESM associates the new session with the task identifier,and in block 1708 initiates the task that corresponds to the designatedtask identifier using any designated parameters. The ESM then continuesin block 1709.

In block 1709, the ESM obtains the current screen (after running anydesignated input) and forwards the current screen to the client-siderequester, which in the DBMS is the client-side host interface of theRBMS. The ESM then does any other activities, and waits for the nextrequest. Although the ESM logic is shown to execute synchronously, insome embodiments it uses asynchronous calling mechanisms to determinewhen a request is to be processed.

In some embodiments, as mentioned with respect to FIGS. 15 and 16, aclient application optionally may request execution of legacy tasks thatare on remote computing systems. In such a case, additional logicinstructions are added to divert to block 1711 after authorizing theuser in block 1702. In block 1711, the ESM determines whether therequested task is a non-local task and, if so, continues in block 1712,otherwise progresses to block 1704.

In block 1712, the ESM processes the non-local task request byforwarding the request to the remote ESM. The remote ESM then processesthe request using similar logic to FIG. 17A, typically without thenon-local task test branch (blocks 1711-1713). In block 1713, the ESMreceives a resultant output screen (data stream from the requested task)from the remote ESM and continues with block 1709 to forward the datastream to the requestor.

All of the above U.S. patents, U.S. patent application publications,U.S. patent applications, foreign patents, foreign patent applicationsand non-patent publications referred to in this specification and/orlisted in the Application Data Sheet, including but not limited to U.S.Provisional Patent Application No. 61/280,034, entitled “ROLE-BASEDMODERNIZATION OF LEGACY APPLICATIONS,” filed Oct. 28, 2009; U.S.Provisional Patent Application No. 61/280,044, entitled “SESSION POOLINGFOR LEGACY APPLICATION TASKS,” filed Oct. 28, 2009; U.S. ProvisionalPatent Application No. 61/280,040, entitled “MODERNIZATION OF LEGACYAPPLICATIONS USING DYNAMIC ICONS,” filed Oct. 28, 2009; U.S. ProvisionalPatent Application No. 61/280,060, entitled “DYNAMIC EXTENSIONS TOLEGACY APPLICATION TASKS,” filed Oct. 28, 2009; U.S. Provisional PatentApplication No. 61/280,042, entitled “HOTKEY ACCESS TO LEGACYAPPLICATION TASKS,” filed Oct. 28, 2009; U.S. Provisional PatentApplication No. 61/280,041, entitled “TIERED CONFIGURATION OF LEGACYAPPLICATION TASKS,” filed Oct. 28, 2009; and U.S. Provisional PatentApplication No. 61/280,043, entitled “MANAGEMENT OF MULTIPLE INSTANCESOF LEGACY APPLICATION TASKS,” filed Oct. 28, 2009; are incorporatedherein by reference, in their entireties.

From the foregoing it will be appreciated that, although specificembodiments have been described herein for purposes of illustration,various modifications may be made without deviating from the spirit andscope of the present disclosure. For example, the methods and systemsfor performing role-based modernization discussed herein are applicableto other architectures other than a windowing architecture. Also, themethods and systems discussed herein are applicable to differingprotocols, communication media (optical, wireless, cable, etc.) anddevices (such as wireless handsets, electronic organizers, personaldigital assistants, portable email machines, game machines, pagers,navigation devices such as GPS receivers, etc.)

1. A method in a computing system for facilitating access to multiplecopies of a same executing task of a menu-based legacy applicationexecuting on a host computer system, comprising: receiving an indicationof a request to copy an executing task of the legacy application;causing one or more separate sessions to be started with copies of theexecuting task of the legacy application executing on the host computingsystem; upon receiving a request to access one of the copies of theexecuting task, displaying associated summary representations of each ofthe copies of the executing task to facilitate user selection of thedesired copy of the executing task.
 2. The method of claim 1, furthercomprising: when input is received to indicate one of the displayedsummary representations, displaying the output screen of the associatedcopy of the executing task.
 3. The method of claim 2 wherein thereceived input is at least one of a user-defined hotkey sequence, asystem defined hotkey sequence, a mouse event, or entry of a number. 4.The method of claim 1 wherein the summary representations include textand/or graphics.
 5. The method of claim 1 wherein the summaryrepresentations include a title and information to identify a particularinstance of the executing task of the legacy application.
 6. The methodof claim 1 wherein the summary representations include icons.
 7. Themethod of claim 1 wherein the summary representations are displayed in asingle task workspace.
 8. The method of claim 1 wherein a predeterminedmaximum number of copies of the executing task are supported.
 9. Themethod of claim 8 wherein the maximum number of copies is
 9. 10. Themethod of claim 1 wherein at least one of the copies of the executingtask is an executing sub-task of the task and the associated summaryrepresentations include a title that identifies the sub-task.
 11. Acomputer-readable medium containing content for controlling a computingsystem to facilitate access to multiple copies of a same executing taskof a menu-based legacy application executing on a host computer systemby performing a method comprising: receiving an indication of a requestto copy an executing task of the legacy application; causing one or moreseparate sessions to be started with copies of the executing task of thelegacy application executing on the host computing system; and uponreceiving a request to access one of the copies of the executing task,displaying associated summary representations of each of the copies ofthe executing task to facilitate user selection of the desired copy ofthe executing task.
 12. The computer-readable medium of claim 11, themethod further comprising: when a first input is received to indicate afirst one of the displayed summary representations, displaying theoutput screen of the associated copy of the executing task.
 13. Thecomputer-readable medium of claim 12 wherein the received first input isat least one of a user-defined hotkey sequence, a system defined hotkeysequence, a mouse event, a keyboard shortcut, or entry of a number. 14.The computer-readable medium of claim 12 wherein the method furthercomprises: receiving second input to indicate a second one of thedisplayed summary representations; and displaying the output screen ofthe copy of a second executing task associated with the second one ofthe displayed summary representations without losing state of the copyof the executing task associated with the first one of the summaryrepresentations.
 15. The computer-readable medium of claim 11 whereinthe summary representations include text and/or graphics.
 16. Thecomputer-readable medium of claim 11 wherein the summary representationsinclude at least one of a title, information to identify a particularinstance of the executing task of the legacy application, and/or icons.17. The computer-readable medium of claim 11 wherein thecomputer-readable medium is a memory of a computing system and thecontent is instructions for controlling a computer processor to performthe method.
 18. A computer system configured to facilitate access tomultiple copies of a same executing task of a menu-based legacyapplication executing on a host computer system comprising: a memory;and a module stored on the memory that is configured, when executed to:receive an indication of a request to copy an executing task of thelegacy application; cause one or more separate sessions to be startedwith copies of the executing task of the legacy application executing onthe host computing system; and upon receiving a request to access one ofthe copies of the executing task, display associated summaryrepresentations of each of the copies of the executing task tofacilitate user selection of the desired copy of the executing task. 19.The computer system of claim 18 wherein the module includes instructionsfor execution in the memory of the computer system.
 20. The computersystem of claim 18 wherein the computer system is a client computingsystem that interacts with a remote computer system to cause the one ormore sessions to be started with copies of the executing task of thelegal application.